Zusammenfassung

  • RFC 5151 beschreibt RSVP-TE-LSPs über AS-Grenzen, IGP-Areas und GMPLS-Overlay-Grenzen.
  • Domänen können zusammenhängende Signalisierung, hierarchische Verschachtelung oder Segment-Stitching verwenden und diese Methoden mischen.
  • Der Ingress kann die Methode begrenzen; Grenzknoten wenden zusätzlich lokale Fähigkeit und Richtlinie an.
  • Interne RRO-Hops dürfen durch eine Domänenkennung ersetzt oder entfernt werden, während der Grenzknoten selbst sichtbar bleiben muss.
  • Die Signalisierung funktioniert nach dieser Filterung weiter, doch Managementdiagnose kann unbrauchbar und Fast Reroute ineffizient werden.
  • Ein Ersatzweg ist nur dann ein Diversitätsnachweis, wenn der Berechnungspunkt den geschützten Arbeitsweg und die auszuschließenden Risiken kennt.
  • RRO, DETOUR, Route Exclusion und PCE können dieses Wissen liefern, aber nur innerhalb ihrer jeweiligen Sichtbarkeit.
  • Ein Grenzknoten darf knotenspezifische PathErr-Details zu einer Domänenmeldung verallgemeinern.
  • Während Crankback darf er einen Fehler halten; Erfolg verwirft ihn, vollständiges Scheitern gibt ihn nach oben frei.
  • Notify-Empfänger können auf Grenzen umgeschrieben werden, wodurch lokale Reaktion entsteht, aber eine eigene Weiterleitungskette nötig wird.
  • Bit 4 fordert einen zusammenhängenden LSP und dokumentiert Methodenverhalten, nicht Risikotrennung oder Datenlieferung.
  • Belastbare Führung verlangt getrennte Belege für Arbeitsrisiko, Ausschluss, Backup-Auswahl, Umschaltung und beobachteten Verkehr.

Zwei Tunnel können eine gemeinsame unsichtbare Schwachstelle haben

Die anschauliche Betriebsdarstellung zeigt meist zwei Linien: eine aktive und eine schützende. Aus der Trennung auf dem Bildschirm wird schnell die Aussage, die Dienstleistung sei redundant. Diese Schlussfolgerung ist nur so gut wie die Risiken, die der Berechnungspunkt sehen und ausschließen konnte.

Für einen Schutzweg über lose Hops muss der Knoten, der die Backup-Route erweitert, den zu schützenden Arbeitsweg zwischen Point of Local Repair und Merge Point kennen. Sonst kann er nicht entscheiden, welche Links, Knoten oder gemeinsamen Ressourcen der Ersatzweg meiden soll. Informationen aus RRO, DETOUR, Route-Exclusion-Objekten oder einem PCE können diese Entscheidung stützen.

RFC 5151 schafft jedoch genau die Situation, in der eine Domäne nach außen nur ihre Grenze zeigt. Ein Arbeits- und ein Schutz-LSP können an verschiedenen sichtbaren Grenzpunkten vorbeilaufen und im Inneren trotzdem dieselbe Leitung, Anlage oder nicht offengelegte Ressource nutzen. Der fertige Backup-LSP belegt dann Kapazitätsreservierung und Signalzustand – nicht die behauptete Trennung vom benannten Risiko.

Vertraulichkeit entfernt Details, aber nicht die Grenze

Das Record Route Object ist optional. Es hilft bei Schleifenerkennung und zeichnet die durchlaufenen Hops auf. Eine Domänengrenze darf aus Gründen der Vertraulichkeit interne Knotenkennungen durch eine AS-Kennung ersetzen oder sie vollständig entfernen. Sich selbst darf sie nicht aus dem RRO löschen.

Übrig bleibt ein administratives Skelett: Der LSP trat hier ein und dort aus. Verschwinden kann die operative Anatomie dazwischen. Der Standard sagt ausdrücklich, dass diese Filterung die Signalisierung nicht behindert. Ebenso ausdrücklich warnt er, dass die verlorene Information Managementdiagnosen unbrauchbar machen oder die Zusammenarbeit mehrerer Betreiber erforderlich machen kann.

Diese Asymmetrie erklärt, warum ein grüner Signalstatus kein grüner Assurance-Status ist. Das Protokoll kann genau nach Vorschrift funktionieren, während der Käufer nicht selbst nachweisen kann, ob beide Pfade dieselbe Störungsdomäne schneiden. Ein brauchbarer Vertrag muss deshalb nicht vollständige Topologie verlangen; er muss eine prüfbare Behauptung über konkrete Risikoklassen ermöglichen.

Die Signalisierungsmethode verteilt die Entscheidungsmacht

Bei einem zusammenhängenden LSP bleiben RSVP-Session und LSP-ID über den gesamten Pfad erhalten. Ein verschachteltes Modell transportiert den End-to-End-LSP in einem oder mehreren H-LSPs. Beim Stitching werden getrennt signalisierte Segmente zu einem durchgehenden Datenpfad verbunden. Ein einziger LSP kann in verschiedenen Domänen alle drei Formen kombinieren.

Der Ingress darf Bedingungen setzen. Wenn Bit 4 Contiguous LSP gesetzt ist, darf die Grenze weder verschachteln noch stitch-en. Versteht ein Knoten die Anforderung, kann sie aber nicht erfüllen, meldet er Routing Problem 28. Ist das Bit nicht gesetzt, entscheidet die Domänenrichtlinie im verbliebenen Spielraum.

Diese Freiheit hat einen Zweck. Eine Transitdomäne kann ihr Segment unabhängig reoptimieren, ohne die interne Struktur oder den Zeitpunkt an den Ingress abzugeben. Gleichzeitig kann lokale Optimierung kumulativ einen End-to-End-Nachteil erzeugen. Eine Domäne darf eine Aufforderung zur Reoptimierung ignorieren, wenn ihr eigener Dienst ausreichend erscheint. Ein Methodenbit koordiniert also Konstruktion; es synchronisiert weder Anreize noch Nachweise.

Ein benannter interner Hop kann an der Grenze enden

Das Explicit Route Object trägt die Route, die frühere Berechnungen und verfügbare TE-Information hervorgebracht haben. Enthält es interne Knoten einer Domäne, die solche Angaben nicht akzeptiert, kann die Grenze den Aufbau als Inter-domain explicit route rejected zurückweisen. Sicherheitsrichtlinien können den Path auch still verwerfen oder weniger genaue Fehler liefern.

Bei einem losen IP- oder AS-Hop erweitert die Grenze die Route mit lokaler Berechnung. Endet die Liste hinter der lokalen Grenze, wird das Ziel der RSVP-Session zum nächsten losen Hop. Eine durch H-LSP oder Stitching erzeugte TE-Verbindung kann nicht schlicht als gewöhnliche zusammenhängende Verbindung weitergeführt werden; Fähigkeiten, Constraints und Richtlinien wählen den nächsten Mechanismus.

Das resultierende ERO dokumentiert den Wegentwurf, der alle Autoritäten passiert hat. Es verrät nicht automatisch, welche Alternativen geprüft wurden, welche gemeinsame Gefahr verborgen blieb oder weshalb ein Egress gewählt wurde. Für Schutzbehauptungen muss die Entscheidungsakte deshalb die sichtbare Anforderung mit einer privaten oder attestierten Risikoauswertung verbinden.

Fast Reroute verbraucht genau die gefilterten Informationen

Die Warnung des RFC betrifft nicht nur Menschen im Incident Call. Verfahren, die RRO-Daten verwenden, können nach der Filterung ineffizient werden. MPLS-TE Fast Reroute nutzt diese Daten, um Labels und einen nachgelagerten Merge Point zu bestimmen. Fehlen sie, wird lokale Reparatur nicht unmöglich, aber weniger präzise oder von zusätzlicher Koordination abhängig.

Man sollte daher fünf verschiedene Aussagen auseinanderhalten. Erstens: Ein Backup-LSP existiert. Zweitens: Er ist für eine definierte Arbeitsstrecke berechnet. Drittens: Eine benannte Risikomengen wurde ausgeschlossen. Viertens: Die Umschaltung erfolgte. Fünftens: Nutzverkehr erreichte danach sein Ziel. Keine dieser Aussagen ergibt sich automatisch aus der vorherigen.

Der belastbare Beleg nennt den Point of Local Repair, den Merge Point, die Arbeitsweg-Evidenz, die beim Rechnen verfügbar war, die angewandten Ausschlüsse, den gewählten Pfad und das Messergebnis nach der Umschaltung. Wo Topologie privat bleiben muss, kann ein Betreiber eine Risikofreiheits-Attestation liefern, ohne interne Knoten offenzulegen. Was nicht genügt, ist das bloße Wort „protected“.

PathErr kann präzise beginnen und als Domäne ankommen

Ein fehlgeschlagener Aufbau sendet PathErr zum Ingress. Jede Grenze auf dem Rückweg sieht die Meldung. Wenn Vertraulichkeit es konkret erfordert, darf eine Grenze „Knoten X scheiterte aus Grund Y“ zu „Domäne B scheiterte“ verallgemeinern. Andere Knoten sollen den Fehler nicht verändern, und Grenzen sollen dies nicht routinemäßig tun.

Der Fehler darf nicht einfach unterdrückt werden. Während eines zulässigen Crankback-Versuchs kann die Grenze ihn jedoch halten, einen anderen internen Weg oder eine andere Folgedomäne versuchen und erst danach entscheiden. Gelingt die Alternative, muss der gehaltene Fehler verworfen werden. Scheitern alle Versuche, muss er nach oben weiterlaufen, gegebenenfalls mit aggregierter Crankback-Information.

Damit ist das Ausbleiben einer präzisen Meldung mehrdeutig. Es kann laufenden Versuch, erfolgreiche Umleitung oder Informationsverdichtung bedeuten. Erst eine Kette aus Fehler-ID, Versuch-IDs, Zeitgrenzen und abschließendem LSP- oder Freigabebeleg macht den Zustand unterscheidbar. Ohne sie wird der Schutzbetrieb gerade dann am wenigsten beweisbar, wenn er erfolgreich einen internen Fehler verbirgt.

Notify beschleunigt lokale Reaktion und verschiebt den Beleg

GMPLS Notify kann direkt an einen angegebenen Empfänger gehen. Will eine Domänengrenze das Ereignis für lokale Schutzmaßnahmen sehen, soll sie die Notify-Request-Adresse auf sich selbst umschreiben. Danach muss sie Meldungen prüfen, verarbeiten und weiterleiten, die ursprünglich für den Ingress bestimmt waren.

Das ist eine sinnvolle Delegation: Wer lokal handeln kann, erhält frühzeitig das Signal. Aber der Zustellbeleg wandert mit. Empfang an Grenze C beweist nicht, dass der ursprüngliche Ingress nach Filterung und Weitergabe dieselbe Aussage erhielt. Der RFC hält zudem fest, dass Verarbeitungs- und Weiterleitungsaufwand linear mit der Zahl der Domänen wächst.

Für die Incident-Zeitlinie braucht jede Umschreibung daher einen Vorgänger, einen neuen Empfänger, einen Inhaltsfingerabdruck oder eine zulässige Transformation und eine nachgelagerte Quittung. Sonst zeigt das Monitoring die erste Zustellung als globale Kenntnisnahme und verwechselt lokale Handlungsfähigkeit mit End-to-End-Information.

Sicherheitsbeziehungen sind kein Diversitätsorakel

Benachbarte Verwaltungen sollen eine geeignete Vertrauensbeziehung herstellen, Schlüssel koordinieren, Vertragsattribute prüfen, Signalisierungsraten begrenzen und ausgehende Objekte filtern. Ohne solche Beziehung empfiehlt der Standard, inter-domain RSVP-TE nicht zu aktivieren. Diese Maßnahmen schützen Ressourcen und Topologie gegen Missbrauch.

Ein authentisierter Nachbar kann dennoch berechtigt sein, interne Pfade nicht offenzulegen. Ein korrekt signierter RRO mit gefiltertem Inhalt ist weiterhin gefiltert. Eine zulässige PathErr-Aggregation bleibt ungenau. Eine attestierte Backup-Auswahl belegt nur die Risikoklassen, die Gegenstand der Attestation waren.

Führung muss folglich festlegen, welche Aussage jede Sicherheitsschicht tatsächlich trägt. Kryptografische Integrität schützt das übermittelte Objekt. Richtlinienkonformität schützt die lokale Entscheidung. Disjointness verlangt einen Vergleich der relevanten Risiken. Datenebenen-Wirkung verlangt Beobachtung des Verkehrs. Wer diese Ebenen in einem einzigen grünen Status zusammenzieht, produziert Gewissheit aus unterschiedlichen, nicht austauschbaren Belegen.

Sources

  1. RFC 5151, HTML
  2. RFC 5151, text
  3. RFC Editor record
  4. IETF Datatracker record
  5. RFC 5151 history
  6. RFC 5151 references
  7. RFC 5151 errata
  8. RFC 3209
  9. RFC 3473
  10. RFC 4206
  11. RFC 4420
  12. RFC 5150
  13. RFC 4726
  14. RFC 4208
  15. RFC 4920
  16. RFC 4090
  17. RFC 4873
  18. RFC 4874
  19. RFC 4655
  20. RFC 4216
  21. RFC 4105
  22. RFC 2747
  23. RFC 5152
  24. IANA RSVP parameters
  25. Minimum Initial Specification
  26. On Reality Layers
  27. Running-Code Primacy