Zusammenfassung

  • RFC 5150 verbindet dedizierte GMPLS-Segment-LSPs, sogenannte S-LSPs, zu einem Ende-zu-Ende-LSP.
  • Der Ursprung fordert Stitching mit Bit 5 in LSP_ATTRIBUTES an; das Segmentende bestätigt Bereitschaft mit Bit 5 im RRO.
  • Zur Vorbereitung gehört ein nichtnulles Label, das vor der Zuordnung noch ohne Verkehrsunterbrechung geändert werden kann.
  • Die Bereitschaft erlaubt die spätere Nutzung des Segments, belegt aber nicht die Programmierung der e2e-Swaps.
  • Zwischen den S-LSP-Endpunkten besteht keine Forwarding Adjacency, auch wenn sie in der TE-Topologie benachbart erscheinen.
  • Label und Upstream Label des abstrakten e2e-Hops sind daher vorgeschrieben, bedeutungslos und vom Empfänger zu ignorieren.
  • Tatsächliche Kontinuität entsteht erst durch je einen lokalen Swap am Segmentanfang und -ende, bei bidirektionalem Betrieb in beiden Richtungen.
  • Der e2e-RRO nennt den Segmentendpunkt und verbirgt die internen Knoten und Links des S-LSP.
  • Ein S-LSP darf nur einem e2e-LSP zugeordnet werden und reserviert dafür seine gesamte Bandbreite; das misst keine Übertragung.
  • S-LSP und e2e-LSP werden unabhängig abgebaut; die genaue Wiederherstellungssignalisierung bleibt außerhalb des Standards.
  • RSVP-Authentisierung schützt die Kontrollnachbarschaft, nicht automatisch den getrennten Datenpfad.
  • Vorbereitung, Bindung, Swap-Zustand, verborgene Pfadgesundheit, Recovery und Kundenergebnis brauchen getrennte Belege.

Das Label gehört zu einer Vorstufe

Der Head End eines S-LSP setzt LSP stitching desired in Bit 5 des Attributes-Flags-TLV. Erkennt und unterstützt das Tail End die Prozedur, reserviert es in der Resv-Nachricht ein nichtnulles Label und setzt LSP segment stitching ready im Attributes-Unterobjekt des RRO. Ein Segment mit gelöschtem Ready-Bit darf der Ursprung nicht verwenden.

Zu diesem Zeitpunkt ist das Segment für eine mögliche Zuordnung vorbereitet. Solange noch kein e2e-LSP gebunden ist, kann das Vorbereitungslabel geändert werden, ohne bestehenden Datenverkehr zu stören. Das ist keine Nebensache, sondern ein Beweis für die zeitliche Grenze der Aussage: Ein Wert ist vorhanden, gerade weil die eigentliche Nutzung noch nicht begonnen haben muss.

Versteht das Ziel den Wunsch, kann ihn aber nicht erfüllen, antwortet es mit PathErr, Routing Problem und Wert 30, Stitching unsupported. Eine Implementierung, die das Objekt, nicht aber TLV oder Bit kennt, darf die Anforderung ignorieren. Betreiber müssen deshalb die bestätigte Antwort auswerten; das ausgesandte Bit allein reicht nicht einmal für Vorbereitung.

Die Zuordnung erzeugt noch keinen direkten Hop

Erst anschließend wählt der e2e-LSP das Segment anhand von Switching Type, ERO, Bandbreite und lokaler TE-Policy aus. Obwohl die Endpunkte in der Verkehrsplanung als benachbart dargestellt werden können, entsteht zwischen ihnen keine Forwarding Adjacency. Das S-LSP bleibt ein eigener, möglicherweise mehrgliedriger Pfad.

Ein bidirektionaler e2e-Aufbau sendet über diesen logischen Hop ein Upstream Label im Path und ein Label im Resv. Die Objekte sind formal erforderlich, aber RFC 5150 erklärt ihre Werte ausdrücklich für bedeutungslos und verlangt, dass der Empfänger sie ignoriert. Sie halten den RSVP-TE-Ablauf vollständig; sie benennen keine direkte Datenebenenoperation.

Darum ist das Zählen von Label-Objekten kein Ausführungsnachweis. Es bestätigt Protokollform. Ob Nutzdaten weitergeleitet werden, entscheidet sich an anderen Stellen und zu einem späteren Zeitpunkt.

Zwei lokale Swaps schließen die Lücke

Am Segmenteingang muss der LSR den vorherigen e2e-Abschnitt auf den S-LSP umschalten. Am Segmentausgang muss er den S-LSP auf den folgenden e2e-Abschnitt umschalten. Für einen bidirektionalen Dienst sind die entsprechenden Operationen in Gegenrichtung ebenfalls nötig.

Die beiden Grenzaktionen haben getrennte Eigentümer, Tabellen, Commit-Zeitpunkte und Fehlermöglichkeiten. Ein erfolgreiches Tail-End-Signal kann die Installation am Head End nicht quittieren; ein vorhandener Ingress-Swap sagt nichts über den Egress aus. Der belastbare Beleg kombiniert Lesungen an beiden Grenzen mit beobachtetem Verkehr.

Diese Trennung erklärt, weshalb ein Ready-Bit auch dann wahr bleiben kann, wenn die später benötigte e2e-Programmierung fehlt oder verworfen wurde. Bereitschaft ist eine Voraussetzung. Weiterleitung ist eine Kette ausgeführter Zustandsänderungen.

Die Topologie zeigt absichtlich weniger

Ein S-LSP kann als TE-Link angekündigt und für die Pfadberechnung verwendet werden. Seine Endpunkte sehen dann benachbart aus, obwohl der Datenpfad mehrere Knoten und Links durchquert. Die Ankündigung ist optional und vergrößert bei Nutzung die Link-State-Datenbank und deren Änderungsaufwand.

Im Record Route Object des e2e-LSP wird für diesen Hop die Adresse des S-LSP-Endpunkts oder der unnummerierte Link-Identifier aufgezeichnet. Die internen Knoten und Verbindungen des Segments sollen dort nicht erscheinen. Ein korrektes RRO belegt somit die beabsichtigte Abstraktion, nicht den inneren Weg.

Domänenübergreifend kann ein lokales Segment außerhalb seiner Domäne unsichtbar bleiben; domänenweise Berechnung oder ein PCE ergänzt die Route. Daraus folgen weder physische Diversität noch der Zustand jedes LSR noch der tatsächlich von einem Paket genommene Weg.

Exklusivität ist Buchführung, kein Leistungstest

Stitching arbeitet innerhalb derselben Switching-Schicht. Anders als ein hierarchischer H-LSP, der mehrere höherliegende LSPs tragen kann, darf ein S-LSP nur einem e2e-LSP zugeordnet werden. Seine gesamte Bandbreite wird der einen Bindung zugewiesen.

Nach der Zuordnung soll die unreservierte Bandbreite auf null sinken. Werden mehrere S-LSPs in einem TE-Link gebündelt, bleibt jedes Element einzeln auf eine Bindung beschränkt und die aggregierten Bandbreitenparameter müssen nachgeführt werden. Das verhindert Doppelbelegung bei Berechnung und Admission Control.

Null unreservierte Bandbreite misst aber weder Durchsatz noch Verlust, Latenz oder Anwendungssitzung. Ein Ressourcenledger kann exakt sein, obwohl ein Grenz-Swap fehlt oder der interne Pfad defekt ist. Reservierungsnachweis und Liefernachweis dürfen deshalb nicht in derselben Kennzahl enden.

Lokale Policy besitzt den Entstehungsentscheid

Ein S-LSP kann administrativ konfiguriert oder auf Anforderung dynamisch erzeugt werden. Der aus der Hierarchie bekannte Auslöser an einer Switching-Region-Grenze darf für Stitching nicht wiederverwendet werden. Die angrenzenden Links müssen denselben Switching Type besitzen, und lokale Policy entscheidet über die dynamische Erzeugung.

Diese Policy ist Teil der Provenienz: Version, Eigentümer, ERO-Grenzen, Bandbreite und Auswahl des konkreten Elements. Die Aussage, „das Protokoll“ habe den Pfad geschaffen, entfernt den menschlichen oder automatisierten Entscheider aus dem Audit.

Stitching kann ältere Knoten überbrücken, auch zwischen P2MP-fähigen LSRs. RFC 5150 mahnt zur Vorsicht, weil die Konfiguration RSVP P2MP unattraktiver machen kann. Eine kurzfristige Kompatibilitätsbrücke wird ohne Exit-Kriterium zum langfristigen Lock-in.

Abbau ist eine zweite, unabhängige Reihenfolge

S-LSP und e2e-LSP besitzen unabhängige Sitzungen und Abbauvorgänge. Der eine kann ADMIN_STATUS verwenden, während der andere Zustand unmittelbar entfernt. Ein statisches Segment kann nach dem e2e-Ende bestehen bleiben; ein dynamisches kann nach einer durch lokale Policy bestimmten Leerlaufzeit verschwinden.

Der Abbau des S-LSP sollte als e2e-Fehler behandelt werden und Recovery oder Teardown auslösen. Wie die Wiederherstellung genau signalisiert wird, legt RFC 5150 jedoch nicht fest. Ein ausgelöster Prozess ist noch kein wiederhergestellter Datenpfad.

Die Empfehlung, vor dem Entfernen eines dynamischen Segments ungefähr 30 Sekunden zu warten, begrenzt kollidierende Fehler- und Teardown-Nachrichten. Sie garantiert keine Kundensitzung. Auch eine gültige RSVP-Sicherheitsbeziehung authentisiert Kontrollnachbarn und ihre IP-Identitäten, nicht die Nutzlast auf einer gegebenenfalls anderen Schnittstelle. IANA-Zuweisungen und das redaktionelle Erratum stabilisieren die Semantik, nicht die konkrete Implementierung.

Quellen

  1. RFC 5150, HTML
  2. RFC 5150, Text
  3. RFC-Editor-Eintrag
  4. IETF-Datatracker-Eintrag
  5. Historie von RFC 5150
  6. Referenzen von RFC 5150
  7. Errata zu RFC 5150
  8. RFC 4206
  9. RFC 3209
  10. RFC 3473
  11. RFC 4420
  12. RFC 3477
  13. RFC 4201
  14. RFC 4203
  15. RFC 4205
  16. RFC 2747
  17. RFC 3032
  18. RFC 5151
  19. IANA-RSVP-Parameter
  20. Minimum Initial Specification
  21. On Reality Layers
  22. Running-Code Primacy